Conceptual Modeling of Business Rules and Processes with the XTT Method∗

The paper deals with the problem of modeling business rules (BR) in the business process management (BPM). The paper presents the challenges of BR modeling, and shows some disadvantages of existing, commonly used methods, such as the BPMN. As a solution, an approach based on the XTT/ARD expert system design and implementation method is outlined and discussed. The methods improve the design and modeling of BR, leading to a more complete, and transparent representation of the rule base. 1. Knowledge in Business Process Management Let us begin with a definition of Business Process Management (BPM). In [13] we find the following one: ”supporting business processes using methods, techniques and software to design, enact, control and analyze operational processes involving humans, organizations, applications, documents and other sources of information”. This definition is of extremely high importance, because one can immediately see the main issues or problems connected with the BPM. These are the questions of incorporating human knowledge into BPM systems, knowledge representation, and mining knowledge from BPM systems. Therefore, BPM is strictly linked with such areas of Artificial Intelligence (AI) as Knowledge Management (KM), Knowledge Engineering (KE) and Business Intelligence (BI). ∗The paper is supported by the HEKATE Project funded from 2007–2009 resources for science as a research project. Knowledge is an essential factor in practical BPM. Knowledge related issues include: acquisition, representation, evaluation, and processing. Knowledge representation methods need proper syntax, visual representation, and formal foundations. These issues have been extensively studied in the field of Knowledge Engineering. Before applying any of the knowledge representation techniques, knowledge on processes has to be gathered and acquired both from existing systems and people. While the first task is not very complicated, the second one is not trivial. In AI, rules are probably the most popular choice for building knowledge-based systems (KBS), that is the rule-based expert systems [3, 5]. Rule-based systems (RBS) are used extensively in practical applications, especially in domains such as automatic control, decision support, and system diagnosis. They constitute today one of the most important classes of KBS. Practical construction of a rule-based knowledge base, also referred to as the rulebase involves number of important steps. These include rule attribute specification, rules design, evaluation, and a practical implementation. Recently, a new approach to practical knowledge representation based on rules, has been gaining popularity. This is the so-called Business Rules Approach (BR). As stated in [2], ”a business rule is a statement that defines or constraints some aspect of the business. It is intended to assert business structure or to control or influence the behavior of the business”. Further information on the BR approach is given in Section 3. The focus of the paper is on the design and modeling of BR in the BPM (Sect. 2). It includes the discussion of the most important issues concerning practical design of business rules (Sect. 3), found in the BPM. In the paper a new design method is described, using an example business rulebase described in Sect. 4. This example has been originally designed using the BPMN (Business Process Modeling Notation) [10], and accompanied with business rules. The method presented in this paper, is centered around the XTT approach, presented in Sect. 5. The Sect. 6 discusses, how applications of these methods could improve aspects of BPM. The paper ends with concluding remarks in Sect. 7. 2. Business Process Modeling The main features of business process modeling are: descriptive what happens during a business process, in what way the process has been performed, what improvements have to be made; prescriptive allows for a definition of a business process and how a process should be performed, it lays down rules, guidelines and behavior patterns; explanatory links processes with the requirements explains the rationale of business processes. These aims lead to the formulation of the requirements that a business process model has to fulfill. First of all, a model has to provide a holistic approach dealing with organizational and technical issues [4]. Next, BP models should have a strong formal foundation. It is so because formal models are unambiguous, and increase the potential for analysis [13]. There are several techniques for BP model specifications. Some are based on Petri nets [13], some make use of the UML notation. It must be nevertheless pointed out that UML, although widely used and adapted, is not expressly designed to map to business execution languages. The two formalized approaches to business process modeling, that are worthy mentioning are the Business Rules Project [2] and the Business Process Modeling Notation [10]. 3. Business Rules Concepts and Tools Business Rules (BR) approach [12, 14] is based on concepts borrowed from knowledge engineering and rule-based systems. It is becoming an important approach in business application development, especially on the Java platform. A classic description of the main principles of the approach is given in [12]. According to it, rules should be: written and made explicit, expressed in plain language, motivated by identifiable and important business factors, single sourced, specified directly by people who have relevant knowledge, managed, and built on facts, and facts should build on concepts as represented by terms. Rules should also exist independent of procedures and workflows. There are number of rule types identified in the BR approach, e.g. reactive, transformation, derivation rules. Business rules design uses some established visual representations. Depending on the design approach these are some classic tools such as simple propositional decision tables, or some high-level conceptual tools such as URML [6]. There are attempts to officially define main aspects of the approach. A good example is the Semantics of Business Vocabulary a Business Rules Specification, see [11]. From the point of view of formal knowledge engineering, some major issues can be pointed out. They are related to: a) logical foundations, b) visual representation, and c) formal analysis and verification of BR systems. The first problem concerns the logical foundations of BR systems. From a point of view of classical KE, a rule-based expert system consists of a knowledge base and an inference engine. The KE process aims at designing and evaluating the knowledge base, and implementing a proper inference engine. The process of building the knowledge base involves the selection of a knowledge representation method, knowledge acquisition, and possibly low-level knowledge encoding. In order to create an inference engine a reasoning technique must be selected, and the engine has to be programmed. In the formal analysis of RBS [5] these important aspects of the design and implementation are identified and analyzed. Unfortunately it can be observed, that common approaches to BR tend to mix these formal aspects. The concept of “business rules types” is both misleading and imprecise. A proper formal analysis of BR should provide a more adequate classification of BR. The second problem is related to the visual representation used in the design of BR systems. Visual representations used, have scalability problems (it’s easy to draw diagrams of several rules, but it becomes very difficult to cope with tens of rules). Lack of well-defined formal foundations of these representations leads to problems with an automatic transformation of the visual model to a logical one. The third problem concerns the formal analysis end verification of BR systems. As the number of rules exceeds even relatively low quantities, it is hard to keep the rule-base consistent, complete, and correct. These problems are related to knowledge-base verification, and validation. The selection of appropriate software tools and programming languages is non-trivial either. These issues are very rarely considered in the BR design. It seems that analysis (where issues such as verification, validation, and evaluation are even not properly separated) is simply considered testing. So the analysis of the knowledge base is implicitly substituted by testing of the implementation. However, in the KE approach, a proper analysis of the knowledge base minimizes the need for testing. 4. Business Rulebase Design Example Let us consider a classic illustrative BR example, presented on the Business Rules Forum in 2005 [1]. The example concerns the UServ Financial Services Company, which provides a full service portfolio of financial products, including: Insurance, and Banking. UServ plays a balancing act between rewarding their best clients and managing the risk inherent in providing on-going service to clients whose portfolios are profitable, but violate the eligibility rules of individual products. UServ’s business rules are an essential component for managing this risk. The business rules address eligibility, pricing and cancellation policies at both the individual product and portfolio level. The case study [1] focuses on UServ’s vehicle insurance products, but differentiates the basic business rules from those that apply to preferred and elite clients. In the BR rulebase three groups of rules are identified: Client Segmentation Business Rules, Eligibility Business Rules, and Pricing Business Rules. Underwriting Decision? + Score Policy Route to Underwriting Determine Premium Notify of Ineligibility Premium Return Eligibility Score between 100 and inclusive Eligibility Score greater than 250 Eligibility Score less than 100